Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 97.25%. Comparing base (37d0605) to head (6e28237).

@@            Coverage Diff             @@
##             main     #822      +/-   ##
==========================================
+ Coverage   97.24%   97.25%   +0.01%     
==========================================
  Files         107      108       +1     
  Lines        7915     7982      +67     
==========================================
+ Hits         7697     7763      +66     
- Misses        218      219       +1     

Shouldn't the protocol also have an update function where it writes the depletion_time on the platform?

Shouldn't the protocol also have an update function where it writes the depletion_time on the platform?

How would you fit it ?

Shouldn't the protocol also have an update function where it writes the depletion_time on the platform?

How would you fit it ?

I am not familiar with the experiment. I was just asking if this protocol is supposed to measure the depletion time.
If not forget it.

Shouldn't the protocol also have an update function where it writes the depletion_time on the platform?

How would you fit it ?

I am not familiar with the experiment. I was just asking if this protocol is supposed to measure the depletion time. If not forget it.

It would involve comparing two allxy plots, the one coming from this routines and the one coming from the regular allxy and getting the smaller delay when they look similar enough I guess.

It would involve comparing two allxy plots, the one coming from this routines and the one coming from the regular allxy and getting the smaller delay when they look similar enough I guess.

Then we should implement a protocol that does exactly this, right? (Outside this PR)

It would involve comparing two allxy plots, the one coming from this routines and the one coming from the regular allxy and getting the smaller delay when they look similar enough I guess.

Then we should implement a protocol that does exactly this, right? (Outside this PR)

Either that or we go for the QM way of getting this for the fit.

The use of reset schemes should also reduce the delay between shots (relaxation_time runcard parameter), no? It would be good to also have this new time somewhere.

The use of reset schemes should also reduce the delay between shots (relaxation_time runcard parameter), no? It would be good to also have this new time somewhere.

Yes, the active reset schemes will lower the relaxation time, but they will be somewhat limited by this resonator depletion time as you could not adress the qubit properly until the photons are depleted (They are also another schemes to active deplete the resonator to make all this faster). For now, I made this to store it in qibolab qiboteam/qibolab#895.

I see. I thought this was a reset scheme, my bad.

@alecandido Should probably take note of this when conditional logic is implemented in Qibolab pulse sequencing, which is probably a necessary feature to add eventually, since QM and Zurich already supports this (and probably can have an initial implementation with fast_reset in ExecutionParameters).

@Jacfomg Have you tested the depletion time with the active reset, if it improves the fidelity?

@sorewachigauyo Yes, conditioning pulses on measurement outcomes is currently unsupported.

Interface-wise, it shouldn't be a too complex addition. Though it is not well-fitting the idea of a pulse sequence, and it would make it closer to a program. So, it is simple only as a patch.
I have the feeling that going towards full-fledged support for flow control, it would make us rebuilding QUA (or anything like the other DSLs), since that will resemble more a program with a processor/interpreter (i.e. the sequencer), rather than a pre-compiled sequence.

@alecandido Should probably take note of this when conditional logic is implemented in Qibolab pulse sequencing, which is probably a necessary feature to add eventually, since QM and Zurich already supports this (and probably can have an initial implementation with fast_reset in ExecutionParameters).

@Jacfomg Have you tested the depletion time with the active reset, if it improves the fidelity?

Let's just say that for now it is not supported anymore for the Zurich driver (I made a crappy implementation to try to overcome qibolab limitations a while ago, that we removed now). I tested active reset with Zurich before being aware of this so results were bad, I expect better performance after waiting the resonator relaxation time. Still, we would need to understand first how to optimize the QND of the readout as right now 1/10 states 1 measurered, when I tested this with QM, were then measured again and were 0s, so they didn't keep the state after measurement for a effective active reset scheme.

(Sorry I edited your comment instead of replying, I edited it back)

@sorewachigauyo Yes, conditioning pulses on measurement outcomes is currently unsupported.

Interface-wise, it shouldn't be a too complex addition. Though it is not well-fitting the idea of a pulse sequence, and it would make it closer to a program. So, it is simple only as a patch. I have the feeling that going towards full-fledged support for flow control, it would make us rebuilding QUA (or anything like the other DSLs), since that will resemble more a program with a processor/interpreter (i.e. the sequencer), rather than a pre-compiled sequence.

At least Zurich has a way of checking if the measurement result was a 0 or a 1. So, having some pulse parameter to tell some of the pulses to be played in those situations would be enough for now. That would also allow for custom active reset sequences instead of just the pi_pulse I applied to the state 1 on my trials.

At least Zurich has a way of checking if the measurement result was a 0 or a 1. So, having some pulse parameter to tell some of the pulses to be played in those situations would be enough for now.

Yes, and that's why I said we could implement it as a patch. We could just label a pulse with the id of another measurement, and resolve the translation in the drivers.

That would also allow for custom active reset sequences instead of just the pi_pulse I applied to the state 1 on my trials.

Point is that, for sequences, we need to label all the pulses. Feasible, but hits the boundary. If you wanted to nest two different ifs, then we'd stop there, or we should start implementing boolean operations in the labeling ids, and that would be a mess...
At that point, much better to give up on the idea of the sequence, and switch paradigm for a program.

At least Zurich has a way of checking if the measurement result was a 0 or a 1. So, having some pulse parameter to tell some of the pulses to be played in those situations would be enough for now.

Yes, and that's why I said we could implement it as a patch. We could just label a pulse with the id of another measurement, and resolve the translation in the drivers.

That would also allow for custom active reset sequences instead of just the pi_pulse I applied to the state 1 on my trials.

Point is that, for sequences, we need to label all the pulses. Feasible, but hits the boundary. If you wanted to nest two different ifs, then we'd stop there, or we should start implementing boolean operations in the labeling ids, and that would be a mess... At that point, much better to give up on the idea of the sequence, and switch paradigm for a program.

Ah yes, but with the patch we could play with some simple active reset schemes that may cut down the relaxation time a lot or just some checks, even if it is just a conditional if you measure a 0 skip the relaxation time and just do resonator deplation and if you measure 1 wait the relaxation time. Just so maybe you could consider this for the qibolab 0.2. Also, the several mesurements seems a bit for more advanced active reset schemes or error correction.

Yes, definitely, I would do that (you could even add an issue in Qibolab, if not yet there, and add the milestone 0.2).

I hope the patch will be backward compatible, I have to think about that (I'm mainly worried about deserialization, since it will be an additional argument). If it is, we don't even need to do necessarily in 0.2.0 or postpone it forever, to avoid breaking, but rather release 0.2.0 asap, and then implement it in 0.2.1.

(The program approach is for sure breaking, and it would be 0.3 or further, no way it could land in current 0.2)

Yes, definitely, I would do that (you could even add an issue in Qibolab, if not yet there, and add the milestone 0.2).

I hope the patch will be backward compatible, I have to think about that (I'm mainly worried about deserialization, since it will be an additional argument). If it is, we don't even need to do necessarily in 0.2.0 or postpone it forever, to avoid breaking, but rather release 0.2.0 asap, and then implement it in 0.2.1.

(The program approach is for sure breaking, and it would be 0.3 or further, no way it could land in current 0.2)

You have this already qiboteam/qibolab#592 , so I won't create another active reset issue if this is okay for you